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1 TRANSACTION DATA TRANSLATION SYSTEM 

2 BACKGROUND OF THE INVENTION 

3 Field of the Invention 

4 The present invention relates to a system and method for data translation, and more 

5 particularly, to a system and method for the translation of financial transaction data in the 

6 environment of operational databases. 

7 Brief Description of Related Art 

8 Analytic and Operational Databases 

Q 9 Conventional software applications typically utilize databases stored in computer- 



lit 0 readable memory for storing associated data. A database is a computerized record-keeping 

hi 

rtf 1 system involving data, hardware on which the data is physically stored, and software capable of 

%2 accessing the hardware to provide a standard method for storing, retrieving or modifying the 

:'J3 data. Paper-based "databases", such as libraries and filing cabinet-type filing/storage/retrieval 

j34 systems, have long been in existence. Computerized databases evolved in the 1960s to solve 

M 5 problems associated with paper-based databases, including enormous physical space 

16 requirements, slow access to data, complexity to learn and use, inability to continually keep data 

17 adequately updated, lack of accuracy, difficulty in sharing data between multiple users, and lack 

1 8 of security. Computerized databases solved these problems by providing a compact, fast, easy to 

19 use, current, accurate, shareable and secure means for storing, obtaining and modifying data, 

20 regardless of the amount of data being handled. Traditional computer databases for business 

21 applications, including Oracle™ and Sybase SQL Server™ ran on large mainframe computers. 

22 As personal computers became less expensive and more powerful, the average computer user 



1 began utilizing databases, such as dBase and Microsoft Access , for a variety of 

2 applications. 

3 With the recent growth of the Internet and the World Wide Web, databases now 

4 constitute an integral part of many web sites, particularly those delivering content to users and 

5 permitting users to transact business over the Internet. For example, an online database of 

6 information such as stock quotes or magazine articles typically permits users to retrieve desired 

7 information by browsing the information stored on its database by category or searching the 

8 database for specific items. The type of database in the foregoing example is called an analytic 

0 9 database, or OLAP (On-Line Analytic Processing), and is one of two main categories of 

H 10 databases. An analytic database is primarily a static, read-only database for storing historical or 

J-ft 1 archived data for purposes of analysis. Another example of the use of an analytic database 

ml 2 would be storing information about sales of homes in a city over a certain period of time, for 

•i 

01 3 purposes of analyzing marketing strategies in relation to demographics. 

m 

1314 Substantially unlike the analytic database, the second category of database is the 

|3l 5 operational database, or OLTP (On-Line Transaction Processing), which facilitates and manages 

16 transaction-oriented applications. An operational database facilitates modifying (i.e. adding, 

17 changing, or deleting) data, thus providing a means for managing information which is more 

1 8 dynamic than in an analytic database. Operational databases are typically used to track 

19 information which is updated in real time. An example of an operational database is a database 

20 used to track inventory in a warehouse supplying a web-based online store. In such a scenario, 

21 information stored in the operational database would be dynamically updated as customers order 

22 products from the store. The database would typically be configured to track the number of 

23 items sold and to provide notification when a reorder of stock is needed. Industries utilizing 
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1 operational databases generally include those requiring large numbers of data entry and retrieval 

2 transactions, such as banking, airlines, mail order, e-commerce, supermarkets, and 

3 manufacturers. Due to the massive volume of information inherent in most operational 

4 databases, modern online transaction processing increasingly requires support for transactions 

5 that span a network and may include multiple entities. For this reason, many operational 

6 database software applications use client-server processing and brokering software that allows 

7 transactions to run on different computer platforms within a network, such as a local-area 

8 network, wide-area network, or the Internet. 

Q 9 While operational databases facilitate modification of data, the modification is not 

j^io usually achieved by directly accessing the data in the database. Instead, a "transaction" is used 

jfl 1 to add, modify, or delete database data. A transaction (e.g. a SAP iDOC) is an instruction to 

ijJ2 alter data in the database along with the appropriate data for carrying out the alteration, i.e. data 

1313 is input and changed in the tables by an application executing transactions. A transaction, 

Q14 depending on its nature, can involve the manipulation of only a few fields, hundreds of fields, or 

Ol5 a very large number of fields. A business relying on an operational database in its operations has 

5"""s 

16 predefined transactions which enable the business to operate. Proper execution of these 

17 transactions is required to keep the business running properly. Businesses typically hire 

18 consultants to help in defining the required transactions, as well as to design and author software 

19 applications which perform the required transactions in the operational database. 

20 Electronic Data Interchange (EDI) 

21 Transactions performed on databases no longer need to be executed locally at the 

22 computer on which the database resides. Although modems and various local and wide area 

23 networks have been available for some time to allow transactions to be remotely executed, the 
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1 recent growth of the Internet/World Wide Web has made it inexpensive and relatively simple for 

2 geographically remote entities to perform transactions on the databases of one another, 

3 particularly due to the advent of new server technology and sophisticated online security 

4 systems. 

5 Whether by modem, network, internet, or other means, EDI (electronic data 

6 interchange) is the common method used to send information from one computer to another. EDI 

7 can also be described as the computer-to-computer exchange of routine business transactions in a 

8 standard format between organizations. EDI is a critical part of electronic commerce because it 
O 9 enables computers to exchange data electronically, which is much faster, cheaper, and more 

r 10 accurate than a paper-based system. To gain the maximum benefits of EDI, an organization's 

Ji'l 1 systems must have two characteristics. First, the flow of information must be integrated, i.e., the 

jtl2 data must flow between automated business management systems using EDI software without 

q13 being re-keyed. Second, the automated business management systems must be intelligent, i.e. 

m 

pi 4 these systems must be able to automatically process routine transactions according to those limits 

□15 defined by the businesses conducting trade. 

16 EDI transactions represent paperless business information exchanges that are 

17 independent of either partner's unique business processes, computer software, or hardware. This 

18 approach provides flexibility and does not impose the requirement of common hardware, 

19 software, business processes, or terminology upon the diverse participants, only common data 

20 usage and transmission formats. Even if EDI is used to simply replace paper while leaving the 

21 existing business processes in place, benefits include reduced data entry and mailing costs, more 

22 accurate information, faster communications, and decreased paperwork and reproduction. 

23 However, fully exploiting the EDI potential requires reengineering the business to bring about 
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1 the greater advantages of faster processing of actions, availability of timely and accurate data for 

2 decision-makers, lower personnel requirements, and a responsive environment that supports 

3 innovations, such as direct vendor delivery, flexible manufacturing, rapid distribution, and 

4 central pay. 

5 In 1979, the American National Standards Institute (ANSI), which is the clearinghouse 

6 and coordinator for standards in all areas of trade and commerce, chartered the Accredited 

7 Standards Committee (ASC) XI 2 to develop and maintain standards for EDI. The ASC is 

8 composed of voluntary representatives from industry, labor, consumer, and government to 

y 9 prepare consensus standards. Upon public comment and approval, ANSI ASCs publish national 

FlO standards. ANSI XI 2 standards, usually simply referred to as XI 2, are the most commonly used 

j^l 1 EDI standards in North America. ASC X12 was chartered to handle business transactions but 

ifi 12 has been expanded to include many other transactions and industries. For example, the Federal 

□ 1 3 Information Processing Standard Publication 1 6 1 (FIPS- 161) dated September 1 99 1 requires all 

m 

□ 14 Federal agencies that exchange business information electronically to use existing XI 2 

0 15 standards. The transactions involved in EDI are data descriptions of business functions, such as 

16 invoicing, purchasing, applications, etc. Standards are defined as the technical documentation 

17 approved by the ASC X12, including transaction sets, segments, data elements, code set, and 

18 interchange control structure. Standards prescribe the framework for formatting a specific EDI 

19 message (or "transaction"), i.e. a block of information making up a business transaction or part 

20 of a business transaction, and each type of transaction or "transaction set" is identified by a 3- 

21 digit number. As of 1999, there were almost two hundred transaction sets supporting the 

22 following business areas: communications and controls, product data, finance, government, 



5 



1 materials management, transportation, purchasing, industry standards transition, distribution and 

2 warehousing, and insurance. 

3 For example, each transaction set used in the Department of Defense EDI meets ANSI 

4 XI 2 criteria and is designed to replace a paper "document" currently used in the paper-based 

5 procurement process. In this scenario, transaction set 840 is a request for quotation (RFQ). The 

6 840 transaction set provides the information that is required to conduct a business action 

7 consisting of transmitting a RFQ. Likewise, an 843 transaction set is the trading partner's 

8 response to the RFQ, and finally, the 850 transaction set is the purchase order issued by the 
^ 9 Department of Defense. Another example is the use of EDI in health care eligibility 

f 1 0 transactions, in which the 270 is the inquiry transaction, which allows a health care provider to 

iA 1 ask a detailed question about coverage of an individual for a benefit. It identifies the provider 

ijll 2 making the inquiry, the individual who is the subject of the inquiry, and the benefit being 

013 inquired about. Transaction 271 is the response to this inquiry, and is able to convey detailed 

IB 

Q 14 information describing the benefits, restrictions, limitations, co-pay amounts, remaining visits, 

y 15 and so forth. The 271 is also used within managed care environments to convey information 

□ 

1 6 describing health plan benefit packages and membership rosters. 

17 The ANSI ASC X12 "standards" are essentially a uniform syntax for packaging ASCII 

1 8 data items, along with a set of standard, predefined code-table values and cross-references. The 

19 syntax is simple, applying a lightly-structured set of labels and positional rules, and a looping 

20 structure, on ordinary ASCII characters. The key feature of an XI 2 standard message is that it is 

21 totally independent of the mechanical means of transmittal of information. The standards are for 

22 the interchange of data: information can be coded in XI 2 on one platform and application 

23 program, and transmitted - using floppy diskette, magnetic tape, or by any type of real-time or 



6 



1 I 



1 batch or packet telecommunication, or a combination of these methods - to any other platform 

2 and application program having an electronic X12 interpreter. The standards control simply the 

3 coding format used, rather than the transmission method. 

4 ANSI ASC XI 2 syntax rules and code values are organized at four levels of detail 

5 (listed here from the most detailed to the highest level of generality): data element dictionary, 

6 segment directory and positional rules, transaction set standards, and transmission control 

7 standards. From the most general to the most detailed, the XI 2 standards work as follows: The 

8 transmission (or interchange) control standards provide for the overall electronic envelope in 

9 which one or more X12 messages are carried from sender to receiver(s). Each interchange 
5^10 consists of one or more transaction sets. Each transaction set is roughly equivalent to a generic 

ru 

jpl 1 "type" of business paper document, such as an Invoice, or a Purchase Order, or a Report of Test 

ml 2 Results. Each type of transaction set, in turn, is made up of a series of "segments" - each 

□ 13 roughly equivalent to a "line", "block", or "field" of related data on a paper form. Finally, at the 

13 14 most detailed level, the data element dictionary provides definitions for the "data elements" — 

y 15 individual atoms of data which are assembled to compose each segment of information in the 

16 electronic transaction. 

17 The data element dictionary defines the data elements that can be transmitted and 

18 provides a standard identifying code for each element. Data elements are the XI 2 "atoms", the 

19 basic building blocks of the record being transmitted. For example, in the environmental arena, 

20 these can include alphanumeric elements such as the name and address of a facility, its permit 

21 number or waste ID code, or numerical data such as flow rate, concentration, or statistical 

22 sampling parameters. Additionally, the X12 dictionary contains tables of predefined code values 

23 for commonly encountered items of business data. An example of data elements often found 
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1 together are the telephone number of a point of contact; the XI 2 reference code is "TE," which 

2 when encountered tells the receiver that the following data item (e.g. "603-555-1212") should be 

3 interpreted as a telephone number rather than a fax or pager number. The value "TE" is an 

4 example of a standard, predefined XI 2 code value, and the phone number itself is an example of 

5 a user-supplied value. The X12 standards provide a powerful combination of predictable 

6 positions - or data "pigeonholes" « in which to place or find both kinds of elements of data. 

7 The segment directory gives the code names and positional rules for logical and 

8 predefined combinations of related data elements. For example, the segment directory shows a 
^ 9 combination called "DTM" specifying that "date-and-time" usually has three related data 
^10 elements. The first might be a code number or character indicating the kind of date to follow, 
ml 1 such as shipping date, invoice date, publication date, or other pre- specified date. The second 
m 12 element would contain the date itself, using six digits, and the third would be the time of day. 
0 1 3 Special characters separate data elements within a segment, and mark the termination of each 

sw 

□ 14 segment and the beginning of the next segment. Another example of a segment might be the 

S 15 name and telephone number of the "person to contact" which is coded in X12 as: 

2—1 

16 PER*1C*W.M. Smith*TE*6035551234*N/L 

17 where "PER" is the identifier for the segment, and "1C" and "TE" are the reference codes for 

1 8 person name (W.M. Smith) and phone number (603555 1 234). "N/L" signifies end of segment. 

1 9 The transaction set standards define the contents of a single generic type of document, 

20 such as invoices, purchase orders, requests for quotation, and shipping manifests. As seen in the 

21 examples above, the XI 2 committee uses a three-digit number for each type of electronic 

22 document. As an example, a purchase order has a standard-development track number of 850, 

23 the invoice is an 810, and a request for quotation is an 840. While a standard ID number is under 

8 



1 review, it carries a prefix of "dp" (for draft proposed). Returning to the example of the 

2 environmental arena, transaction set standards would be developed for facility inventory forms, 

3 monitoring reports, or other documents of a similar type. The standards simply define the data 

4 segments which make up the document in the order they are to be transmitted. For the user, it is 

5 transmission of the transaction set which is the real purpose for the entire effort. 

6 Transmission control standards define the "envelope", or the "letter of transmittal" for 

7 the transmission of the electronic documents (i.e., transaction sets). They define such items as: 

8 how transaction sets are identified and how beginnings and endings of the documents are 
^rj 9 defined, grouping of the sets, identification of sender and receiver, and procedures for 

5: : 

'EST 

f : jlO transmitting and for acknowledging receipt. These standards also establish means by which 

ml 1 documents of similar type are grouped for transmission, and provide means by which more than 

m 12 one category of document can be forwarded in one transmission. 

p 13 In practice, the originator of an electronic message uses the X12 standards to construct 

m 

0 14 a message which could be easily interpreted by a recipient familiar with XI 2, or, more 

XI 

□ 15 importantly, the recipient's data processing equipment. The originator looks in the data element 

16 dictionary to identify how each element in his message should be coded. Then the sender must 

17 sequence each of those elements in the order established in the segment dictionary. Each of those 

18 segments is in turn placed in a segment sequence specified in the transactions set. The originator 

19 separates data elements within a segment with some predefined symbol, such as an asterisk, then 

20 separates segments with other symbols such as "N/L". The result is a computer message which 

21 corresponds to a single hardcopy document — a transaction set built from predefined segments 

22 made up of predefined data elements in a predefined order. 
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1 Several types of documents might be combined in a single transmission. For example, 

2 an originator might wish to transmit five invoices, fourteen purchase orders, and three requests 

3 for quotation in one session. The sender would simply group all similar documents together. At 

4 the start of the session, an interchange control header would be sent, followed by a functional 

5 group header indicating invoices are to be transmitted, then the five invoices, with transaction set 

6 headers and trailers separating each invoice, followed by a functional group trailer indicating end 

7 of transmission of invoices. The process would be repeated for the purchase orders (functional 

8 group header, invoices with headers and trailers, and functional group trailer), and then again for 

^ 9 the three requests for quotation. Thus, each of the twenty-two individual documents could be 

^y 

f [ 10 viewed as the equivalent of a complete paper document. In the paper world, the sender might 

m 1 1 decide to forward all twenty-two paper documents to the receiver through the mail in one large 

jii 12 addressed envelope, similar to "bounding" the transmission with the interchange control header. 

0 13 Since the invoices, purchase orders, and requests for quotation are routed to different offices 

O 14 upon receipt, the originator might elect to place the three groups of documents into three smaller 

O 15 envelopes with addresses of the various offices, similar to "bounding" each category of 

P 

16 transaction sets with functional group headers and trailers. 

17 Like ANSI ASC XI 2, UN/EDIFACT is a system of standards which define rules for 

18 EDI and syntax between correspondents. UN/EDIFACT is primarily used outside the United 

19 States and/or by international trading partners. Even though the two standards are basically 

20 similar in function and intent, a data translator (or "mapper") must be used to recast XI 2 code to 

21 UN/EDIFACT, or vice-versa. UN/EDIFACT uses the same four groups of standards as ANSI 

22 XI 2: transaction set standards, a data element dictionary, segment directory, and transmission 

23 control standards. Similarities and differences between the two are: Both use data elements as the 
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1 basic building block, though UN/EDIFACT uses a somewhat different method for presenting the 

2 data element. UN/EDIFACT uses a "composite data element" which only recently is being 

3 accommodated within XI 2. The composite data element consists of two or more simple data 

4 elements linked together. The composite shows functional relationships between the elements so 

5 that the same grouping is used consistently. Data segments in the two systems are broadly 

6 similar. UN/EDIFACT uses data elements in the construction of segments and some controls for 

7 repetitive counting; features not used in ANSI XI 2. The UN/EDIFACT equivalent to the ANSI 

8 XI 2 "transaction data set" is the "message". Both require the user to follow a structured 

^ 9 sequence to create the document, and the resulting overall design is very similar. Differences in 

u : 
•ear 

!" : 10 allowed character sets do not affect message design, but might be of concern when the sender 

]i i 

j« 1 1 selects delimiter characters for segments and elements. Grouping of transaction sets (or messages 
ifl 

12 in UN/EDIFACT) for transmission is broadly similar in the two systems, though UN/EDIFACT 

it 

p 13 does not require use of functional group headers and trailers. 

Q 14 Another common data standard for financial transactions is X9, which like XI 2, is 

O 15 accredited by ANSI and developed, established, published and maintained for facilitate delivery 

16 of financial products and services in the financial services industry using voluntary, consensus 

17 technical standards. The inter-industry voting membership of the X9 committee includes over 

1 8 300 organizations representing investment managers, banks, software and equipment 

19 manufacturers, printers, credit unions, depositories, government regulators, associations, 

20 consultants, and others. X9 develops for check processing, electronic check exchange, PIN 

21 management and security, financial industry use of data encryption, and wholesale funds 

22 transfer, among others. Standards under development as of 1999 include electronic payments on 

23 the internet, financial image interchange, home banking security requirements, institutional trade 
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1 messages, and electronic benefits transfer. Specifically, X9 deals with paper-based financial 

2 instruments, as well as the MICR line of US-based checks, thereby facilitating the movement 

3 away from paper-based transactions and towards e-commerce-based transactions, as well as the 

4 integration of and interaction between e-commerce and EDI systems of varying methods. 

5 Despite the ultimate goal of EDI to standardize transactions, there is no true single 

6 standard governing the format of a transaction, as a practical matter. Even within the Federal 

7 Government, each agency has a different system and requirements. Instead, there are multiple 

8 data dictionaries defining transaction formats, with multiple versions which proliferate the 

S 9 business world, both domestically and globally. In addition to the XI 2 document sets discussed 

^10 above, other formats include UN/EDIFACT (United Nations rules for Electronic Data 

1 1 Interchange For Administration, Commerce and Transport), CEFACT (Centre for Facilitation of 

tji 12 Procedures and Practices for Administration, Commerce and Transport), NACHA (National 

□ 13 Automated Clearinghouse Association), and SWIFT (Society for Worldwide Interbank Financial 
Q 14 Telecommunications). From year to year, each of these data dictionaries is updated and a new 

□ 15 version is issued. The update includes the addition of new "codes", or entries, to the data 

16 dictionary, the deletion of codes, as well as modifications of existing codes. For example, as of 

17 the year 1999, at least 13 different versions of X12 were in existence (version 2000 through 

18 version 4030). In a typical X12 version, over 63 data segments, 630 fields of information, and 

19 10,000 codes exist for financial EDI. These statistics are compounded with each and every X12 

20 version. 

21 In a typical EDI environment, a set of tables defining each XI 2 segment, field and 

22 looping structure must be created. With the release of each X12 version, a new and separate set 

23 of tables is required. This approach is cumbersome and requires much recasting of data from 
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1 one format to another. Additionally, such a complicated approach necessitates the hiring of 

2 programmers to write many lines of code, as each data dictionary for each format is updated 

3 from year to year. Moreover, with the multiple data dictionaries that define transaction formats, 

4 such as UN/EDIFACT, CEFACT, NACHA, and SWIFT, as well as the multiple versions which 

5 proliferate the business world, both domestically and globally, there is a need for data 

6 normalization among the data dictionaries of each of the transaction formats, as well as among 

7 the multiple versions of each format. There is also a need for data normalization between data 

8 dictionaries of the foregoing transaction formats and other data formats, such as print image files, 
SQL data sources, and fixed record ASCII. There is further a need for data normalization 

YlO between data dictionaries of the foregoing transaction formats and legacy paper-based financial 

jfl 1 transaction instruments (e.g. checks, cashier's checks, drafts, and other financial instruments). 



02 SUMMARY OF THE INVENTION 

yl3 It is therefore an object of the present invention to normalize a plurality of transaction 

Ql4 format defining data dictionaries with one another. 

1315 It is another object of the present invention to normalize a plurality of versions of a 

16 transaction format defining data dictionary with one another. 

17 It is a further object of the present invention to normalize data of one or more 

1 8 transaction format defining data dictionaries with other data formats, such as print image files, 

1 9 SQL data sources, and fixed record ASCII. 

20 It is yet a further object of the present invention to normalize data of one or more 

21 transaction format defining data dictionaries with legacy paper-based financial transaction 

22 instruments. 
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1 It is still another object of the present invention to provide a system and method for 

2 translating transaction data using a data normalization-based translation engine. 

3 It is still a further object of the present invention to provide improved performance and 

4 simplified storage in a system for processing transactions in an EDI environment. 

5 It is still yet a further object of the present invention to provide a web-based data 

6 normalization portal for translating transaction data. 

7 The present invention involves the normalization of a plurality of varying data 



8 dictionaries and versions of data dictionaries into a single set of tags, which are then used to 

G 9 create one or more payment formats. This normalized approach simplifies data storage and 

P : 10 significantly improves the performance of processing financial transaction based data and files. 
:~ 1 1 In one embodiment of a system according to the present invention, a plurality of 

m 12 transaction format defining data dictionaries are normalized into a single set of tags, and the 

□ 13 relationships between those tags (and thus the corresponding fields of the underlying data 

p 14 dictionaries) is also normalized. These tags, which include a plurality of predefined data fields, 

□ 15 are then used as a core data structure for the data translation process. A first dictionary 

16 corresponds to the input format of the data to be translated. The first dictionary is used to locate 

17 within the transaction data to be translated data which corresponds to at least a portion of the 

18 predefined data fields. The input data is then translated into the core format. A second 

19 dictionary corresponds to the intended output data format and is used to assemble output 

20 transaction data using the core-formatted data representing at least a portion of the predefined 

21 data fields. 

22 In method form, the normalization method comprises the steps of: receiving input 

23 transaction data in an input data format; using at least a first dictionary corresponding to said 
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1 input data format to locate, within said input transaction data, data corresponding to at least a 

2 portion of the predefined data fields of a core data structure having a plurality of predefined data 

3 fields; and using at least a second dictionary corresponding to at least one output data format to 

4 output transaction data in said output data format, said output transaction data corresponding to 

5 at least a portion of the predefined data fields of said core data structure. 

6 A preferred embodiment of the present invention is a web-based transaction data 

7 normalization portal comprising a core data structure having a plurality of predefined data fields, 

8 at least one first dictionary corresponding to at least one input data format, at least one second 
3 39 dictionary corresponding to at least one output data format, and a translation engine residing on a 
-10 network server adapted for communication with a network. The translation engine receives from 
|il 1 a first computer, via said network, input transaction data in said input data format. The 

I?12 translation engine uses said first dictionary to locate, within said input transaction data, data 

H3 corresponding to at least a portion of the predefined data fields of said core data structure. The 

Pi 4 translation engine then uses said second dictionary to output to a second computer, via said 

□ 5 network, output transaction data in said output data format, said output transaction data 

1=5? 

16 corresponding to at least a portion of the predefined data fields of said core data structure. 

17 In one embodiment, the method of the transaction data normalization portal includes the 

18 steps of: receiving from at least a first computer, via a network, input transaction data in an input 

19 data format; using at least a first dictionary corresponding to said input data format to locate, 

20 within said input transaction data, data corresponding to at least a portion of the predefined data 

21 fields of a core data structure having a plurality of predefined data fields; and using at least a 

22 second dictionary corresponding to at least one output data format to output to a second 

23 computer, via said network, output transaction data in said output data format, said output 
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1 transaction data corresponding to at least a portion of the predefined data fields of said core data 

2 structure. 

3 BRIEF DESCRIPTION OF THE DRAWINGS 

4 Figure 1 is a block diagram representation of an embodiment of a transaction data 

5 translator according to the present invention; 

6 Figure 2 is an example of input transaction data which may be received in one 

7 embodiment of the present invention; 

8 Figure 3 is a graphical representation of example EDI transaction data of a portion of 
B 9 the first dictionary in one embodiment of the present invention; 

j^jlO Figure 4 is a graphical representation of a portion of the first dictionary in one 

!« 1 1 embodiment of the present invention; 

; H : 
■:=• - 

p 12 Figure 5 is a graphical representation of a portion of the core data structure in one 

p 1 3 embodiment of the present invention; 

yy 

p 14 Figure 6 is a graphical representation of a portion of the second dictionary in one 

Q 1 5 embodiment of the present invention; 

16 Figure 7 is a process flow diagram of the operation of a translation engine according to 

17 one embodiment of the present invention; and 

1 8 Figure 8 is a system diagram of a preferred embodiment of a translation engine 

19 according to the present invention integrated into a network setting. 

20 It will be appreciated by those skilled in the art that although the following Detailed 

21 Description will proceed with reference being made to preferred embodiments, the present 

22 invention is not intended to be limited to these embodiments. For example, it should be 

23 understood from the outset that although preferably the functional components of the preferred 

16 
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1 embodiments of the system of the present invention are embodied as one or more distributed 

2 computer program processes, data structures, dictionaries or other stored data on one or more 

3 conventional general purpose computers (e.g. IBM-compatible, Apple Macintosh, and/or RISC 

4 microprocessor-based computers), conventional telecommunications (e.g. modem and/or ISDN 

5 communications), memory storage means (e.g. RAM, ROM) and storage devices (e.g. computer- 

6 readable memory, disk array, direct access storage) networked together by conventional network 

7 hardware and software (e.g. LAN/WAN network backbone systems and/or Internet), other types 

8 of computers and network resources may be used without departing from the present invention. 
Q 9 The invention as described herein may be embodied in a computer residing on a 

z f\0 network transaction server system, and input/output access to the invention may comprise 

;il 1 appropriate hardware and software (e.g. personal and/or mainframe computers provisioned with 

jfjl2 Internet wide area network communications hardware and software (e.g. CQI-based, FTP, 

pi 3 Netscape Navigator™ or Microsoft Internet Explorer™ HTML Internet browser software, and/or 

pi 4 direct real-time TCP/IP interfaces accessing real-time TCP/IP sockets) for permitting human 

r 3 

3=;s 

□15 users to send and receive data, or to allow unattended execution of various operations of the 

Q 

16 invention, in real-time and/or batch-type transactions. Likewise, it is preferred that the system of 

17 the present invention be a remote internet-based server accessible through conventional 

18 communications channels (e.g. conventional telecommunications, broadband communications, 

19 wireless communications) using conventional browser software (e.g. Netscape Navigator™ or 

20 Microsoft Internet Explorer™). Thus, the present invention is preferably appropriately adapted 

21 to include such communication functionality and internet browsing ability. Additionally, those 

22 skilled in the art will recognize that the various components of the server system of the present 

23 invention can be remote from one another, and may further comprise appropriate 

17 



1 communications hardware/software and/or LAN/WAN hardware and/or software to accomplish 

2 the functionality herein described. 

3 Preferably, each of the functional components of the present invention are embodied as 

4 one or more distributed computer program processes running on one or more conventional 

5 general purpose computers networked together by conventional networking hardware and 

6 software. Most preferably, each of these functional components is embodied by running 

7 distributed computer program processes (e.g., generated using "full-scale" relational database 

8 engines such as IBM DB2™, Microsoft SQL Server™, Sybase SQL Server™, Oracle 7.3 ™, or 
Q 9 Oracle 8.0 ™ database managers, and/or a JDBC interface to link to such databases) on 

l p 10 networked computer systems (e.g. comprising mainframe and/or symmetrically or massively 

; 1 1 parallel computing systems such as the IBM SB2 ™ or HP 9000 ™ computer systems) including 

IjM 
if) 

% 12 appropriate mass storage, networking, and other hardware and software for permitting these 

n 13 functional components to achieve the stated function. Preferably, these computer systems are 

□ 14 geographically distributed and connected together via appropriate wide- and local-area network 

□ 15 hardware and software. In one embodiment, program data can be made accessible to the user via 

16 standard SQL queries for analysis and reporting purposes. 

17 Primary elements of the invention can be server-based and can reside on hardware 

1 8 supporting an operating system such as Microsoft Windows NT/2000™ or UNIX. Clients can 

19 include a PC that supports Microsoft Windows 95/98/NT/ME/2000 ™ or a UNIX Motif 

20 workstation platform. In a preferred embodiment, no software other than a web browser is 

2 1 required on the client platform. 

22 Alternatively, the aforesaid functional components may be embodied by a plurality of 

23 separate computer processes (e.g. generated via dBase , Xbase , MS Access ,ra or other "flat 
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1 file" type database management systems or products) running on IBM-type, Intel Pentium or 

2 RISC microprocessor-based personal computers networked together via conventional networking 

3 hardware and software and including such other additional conventional hardware and software 

4 as is necessary to permit these functional components to achieve the stated functionalities. In 

5 this alternative configuration, since such personal computers typically are unable to run full-scale 

6 relational database engines of the types presented above, a non-relational flat file "table" (not 

7 shown) may be included in at least one of the networked personal computers to represent at least 

8 portions of data stored by a system according to the present invention. Preferably, these personal 
O9 computers run the Unix, Microsoft Windows NT/2000 ™ or Windows 95/98/ME ™ operating 
\*i0 system. The aforesaid functional components of a system according to the present invention 

1 may also comprise a combination of the above two configurations (e.g. by computer program 

rfI2 processes running on a combination of personal computers, RISC systems, mainframes, 

j:J3 symmetric or parallel computer systems, and/or other appropriate hardware and software, 

?rsf 

04 networked together via appropriate wide- and local-area network hardware and software). 
I3L5 A system according to the present invention may also be part of a larger computerized 

IKS? 

16 bill presentment and payment system comprising multi-database or multi-computer systems or 

17 "warehouses" wherein other data types, processing systems (e.g. transaction, financial, 

18 administrative, statistical, data extracting and auditing, data transmission/reception, and/or 

19 accounting support and service systems), and/or storage methodologies may be used in 

20 conjunction with those of the present invention to achieve an overall information management, 

2 1 processing, storage, search, statistical and retrieval solution for a particular lock box service 

22 provider, e-payment warehouses biller organization, financial institution, payment system, 

23 commercial bank, and/or for a cooperative or network of such systems. 
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1 As those in the art will recognize, another possible embodiment of the invention 

2 includes two-way data encryption and digital certification for data being input and output, to 

3 provide security to data during transfer. A further embodiment may comprise security means 

4 including one or more of the following: password or PIN number protection, use of a 

5 semiconductor, magnetic or other physical key device, biometric methods (including fingerprint, 

6 nailbed, palm, iris, or retina scanning, handwriting analysis, handprint recognition, voice 

7 recognition, or facial imaging), or other log-on security measures known in the art. 

8 In a preferred embodiment, source code is written in an object-oriented programming 
P 9 language using relational databases. Such a preferred embodiment includes the use of 

$J]\0 programming languages such as Java, and certain functions, such as remote payer access, are 

? s i 

N 1 1 accomplished using an application server platform (ASP) such as Safika's NetDynamics™. 

y 1 

12 Other programming languages which can be used in constructing a system according to the 

L 13 present invention include C/C++, HTML, Perl, UNIX shell scripting, assembly language, 

pi 14 Fortran, Pascal, Visual Basic, and QuickBasic. Those skilled in the art will recognize that the 

q 15 present invention may be implemented in hardware, software, or a combination of hardware and 

16 software. The preferred translation engine of the present invention resides in computer-readable 

1 7 memory having a resident algorithm for performing the translation of data as described and 

18 claimed herein. 

19 The translation of EDI-type financial data, particularly of the X12, UN/EDIFACT, and 

20 NACHA formats, as discussed herein, is provided herein only as an example of transaction data 

21 capable of interacting with the invention and should not be construed so as to limit the use of the 

22 invention solely in such a setting. While the discussion herein presumes the use of the invention 
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1 with respect to EDI, transactional, or financial data, it is anticipated that the invention may have 

2 utility in other contexts, as well. 

3 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

4 With reference now being made to Figure 1, preferred embodiments of the system and 

5 process of the present invention will now be described. Preferred embodiment 200 comprises a 

6 core data structure 203, a first dictionary 201, a second dictionary 202, and a translation engine 

7 205 receiving input data 204 and outputting output data 206. While only a first and second 

8 dictionary are described herein with respect to the preferred embodiment for ease of reference, 
O 9 those skilled in the art will recognize that a plurality of dictionaries may be required in order to 
f\ 10 handle the various input and output formats, one dictionary corresponding to each input or output 
|^ 1 1 format. In the preferred embodiment, the input data 204 and output data 206 comprise EDI 

1^ 12 transaction data. Input data 204 and output data 206 can be of one or more of the following 

jU s 13 formats: XI 2 (any or all versions, with any looping structure), UN/EDIFACT, CEFACT, 

q 14 NACHA, SWIFT, print image files, SQL data sources, fixed record ASCII, legacy paper-based 

Q 15 financial transaction instruments (e.g. checks, cashier's checks, drafts, and other financial 

16 instruments), any combination of one or more of the foregoing formats, or any other data format. 

1 7 The core data structure 203 is preferably of an XML (extended markup language) or 

1 8 similar format, but can be of any data format, and comprises a set of fields, commonly referred to 

19 as XML "tags". Ideally, the core data structure 203 is a single set of XML tags, each tag 

20 corresponding to a field or to part of a field in each input and/or output data format, such that at 

21 least one tag exists in the core data structure to represent each data component or sub-component 

22 of each input and/or output data format. The first dictionary 201 corresponds to the input format 

23 of the input transaction data 204 to be translated and is operable to locate within the input data 
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1 204 data which corresponds to at least a portion of the predefined data fields of core data 

2 structure 203. The second dictionary 202 corresponds to the intended output data format and is 

3 operable to assemble output data 206 using the core- formatted data representing at least a portion 

4 of the predefined data fields of core data structure 203. First dictionary 201 may also be used as 

5 an output dictionary for translating data into the format of the first dictionary, and second 

6 dictionary 202 may also be used as an input dictionary for translating data from the format of the 

7 second dictionary into another format. Alternatively, a separate input and output dictionary may 

8 be used for each input and/or output data format. Translation engine 205 receives input data 204 
13 9 in an input data format to be translated and outputs output data 206 in a desired output format, 
p 10 While the first dictionary 201, the second dictionary 202, and the core data structure 203 are 

\** 1 1 generally referred to herein as separate components from the translation engine 205, the first 

12 dictionary 201, the second dictionary 202, and the core data structure 203 may also be 

i«i 1 3 components of translation engine 205 . 

q 14 In operation, the translation engine 205 of system 200 receives input transaction data 

□ 15 204. An example of input data 204 which may be received by system 200 for translation may be 

16 seen in Figure 2. In Figure 2, the input data 204 shown represents an electronic check document, 

17 with a plurality of fields 250. It is noted that the example transactions and data described and 

1 8 shown herein are for illustrative purposes only and include a limited number of fields so that they 

19 can be easily represented in a single diagram. Of course, in an actual embodiment of the present 

20 invention, a transaction may contain a larger or smaller number of fields than is represented 

2 1 herein. Returning now to Figure 1, translation engine 205 identifies the format of the transaction 

22 contained in input data 204 to determine which data dictionary from among a plurality (not 

23 shown) of dictionaries is to be used as the first dictionary 201 to translate the input data 204 into 

22 



1 the format of the core data structure 203. Using the first dictionary 201 , the translation engine 

2 205 then translates the input data 204 from the input format into the format of the core data 

3 structure 203. 

4 With reference now to Figures 3 and 4, an example of first dictionary 201 in one 

5 embodiment of the invention may be seen. Figure 3 is a graphical representation of the EDI data 

6 shown in Figure 2 as the data would appear on a legacy paper check, and Figure 4 is a graphical 

7 representation of a portion of the first dictionary 201 used in the translation of the check data. In 

8 an actual embodiment, the first dictionary 201 is substantially larger than the portion represented 

^ 9 herein, which is for illustrative purposes only. In Figure 4, "<CHK>" identifies that the data 

m 

j* 30 which follows relates to an electronic check document transaction. Fields 101 through 1 12 of 

jJtl 1 Figure 4 correspond to the fields of Figure 3 to represent the check data contained in the 

ifil2 transaction of Figure 2. For each field, first dictionary 201 contains information including the 

5: 

Q13 segment or field identifier 271, the contents of the field 272, whether the field is required or not 

m 

0 14 273 (i.e. whether the transaction can be effected without the field), and the required format 274 
.C 

D 15 for the field. 

16 Referring now to Figure 5, a portion of the core data structure 203 in one embodiment 

17 of the invention is shown, comprising mapping (i.e. translating) instructions for relating field 

18 identifiers 271 from first dictionary 201 (as seen in Figure 4) to the appropriate core data 

19 structure elements 279. In an actual embodiment, the core data structure 203 is substantially 

20 larger than the portion represented herein, which is for illustrative purposes only. It is noted that, 

21 for example, field 109 contains data for two fields of the core data structure, Payor Financial 

22 Institution Address 1 and Payor Financial Institution Address 2. As shown in Figure 5, mapping 

23 instructions are provided therein so that field 109 is properly split into the two corresponding 
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1 fields 279 of the core data structure 203. In a similar vein, it is also noted that in this example, 

2 there are no fields within field identifiers 271 which correspond to Payee Address 1 and Payee 

3 Address 2 of the core data structure 203. Once the input data 204 has been translated into the 

4 format of the core data structure 203, it is available to be translated easily into any desired format 
\ 5 using a second dictionary 202 pre-selected from among a plurality of dictionaries. 

6 Referring once again to Figure 1, translation engine 205 next translates into the desired 

7 output format the input data 204 which has now been translated into the format of the core data 

8 structure 203. This is accomplished by using the second dictionary 202, which corresponds to 
G 9 the desired output format for the transaction data. Figure 6 shows an example of the second 

7 10 dictionary in one embodiment of the invention. In an actual embodiment, the second dictionary 

;i 1 202 is substantially larger than the portion represented herein, which is for illustrative purposes 

3 Sl2 only. Just as in Figure 4, "<CHK>" as shown in Figure 6 identifies that the following data is for 

Hl3 an electronic check document transaction. Fields 301 through 314 of Figure 6 correspond to the 

iVi 

q 14 fields of Figure 3 to represent the check data contained in the transaction of Figure 2. For each 

|D 15 field, second dictionary 202 contains information including the segment or field identifier 371, 

16 the contents of the field 372, whether the field is required or not 373, and the required format 374 

17 for the field. Translation engine 205 utilizes second dictionary 202 to determine the data 

18 necessary for output, as well as the proper output format for the transaction. Referring now once 

19 again to Figure 5, the portion of the core data structure 203 in one embodiment of the invention 

20 shown comprises mapping instructions for relating field identifiers 371 from second dictionary 

2 1 202 (as seen in Figure 6) to the appropriate core data structure elements 279. Returning now to 

22 Figure 1 , translation engine 205 utilizes the second dictionary 202 to translate the input data 204 
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1 which has been formatted in the format of the core data structure 203 into output data 206 in the 

2 output format. 

3 Figure 7 shows the operation of translation engine 205 in one embodiment of the 

4 invention. Translation engine 205 initially receives 400 input transaction data in an input format. 

5 The engine identifies 401 the format of the input transaction data and based on the identified 

6 format selects an appropriate first dictionary. The translation engine 205 then translates 402 the 

7 input data into the core data structure using the selected first dictionary. Next, the translation 

8 engine 205 translates 403 the core data structure-translated input transaction data into the desired 
y 9 output format using a pre-selected second dictionary. Finally, the translation engine 205 outputs 
!f ;10 404 the output transaction data in the desired output format. 

3=S ; 

pi 1 It is noted that a one-to-one correspondence between the input data structure and the 

m 12 output data structure is not necessary. Appropriate mapping instructions are contained in the 

|3 13 first dictionary 201 and second dictionary 202 so that proper translation can occur even between 

□ 14 a field of one data format which does not exist in the second, or vice- versa. If the field exists in 

P 15 the first format but not the second, the data of that field is simply ignored. If the field exists in 

□ 

16 the second format but not the first, a default field is supplied. As seen above, some fields must 

17 be merged or split in order to achieve proper correspondence between data formats, and 

18 dictionaries 201 and 202 contain appropriate mapping instructions to achieve such a 

19 correspondence. The following are other examples of mapping instructions contained in 

20 dictionaries 201 and 202 including the application of algorithms to conflicts between data 

2 1 formats in the normalization process: 

22 As a first example, in one XI 2 version, the DTM (date/time reference) segment 

23 contained the date in the second field of the segment. In the next version, the date was moved to 
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1 the second field to a different field in the segment. In a later version, the field was extended for 

2 century (year 2000) compliance, i.e. to include two extra digits representing the century, and 

3 moved once again. To account for such conflicts, algorithms are defined and applied herein in 

4 the form of mapping instructions, particularly in cases where segments have been recast outside 

5 the rules of data normalization. 

6 As a second example, the core data structure may have a field called "date/time". The 

7 input data 204 structure may have a field defined by the first dictionary 201 as "date" and 

8 another field defined as time "time". Therefore, the algorithm of the first dictionary 201 would 
□ 9 comprise mapping instructions between the core data structure 203 and the first dictionary 201 
CP 10 such that the date/time field of the core data structure 203 is mapped to both the data field and 
i* 1 1 the time field of the first dictionary 201. In operation, the translation engine 205 would start 

m 

';5 12 with the predefined date/time field, look at the mapping algorithm of the first dictionary 201 to 

ir* 

!U 13 find a date field and a time field, and then use the dictionary to find data corresponding to the 

S 14 date field and the time field in the input data 204. 

S 15 As a third example, the date/time field of the core data structure 203 may be formatted 

Q 

16 as DDM1VTYTYYHHMMSS. The date field as defined by the first dictionary 201 may be 

17 formatted as YYMMDD. Therefore, once that data is found in the input data 204, the data must 

18 be reformatted or reorganized (and two digits representing the century must be added) so that it 

19 can be fit into the core data structure 203. 

20 As a fourth example, a data field or segment may need resizing to effect a proper 

21 correspondence between data formats. The first dictionary 201 may contain instructions to add or 

22 remove leading or trailing zeros to make a particular piece of data fit the appropriate size of the 

23 corresponding field. 
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1 As a fifth example, if the input data 204 contains a two-digit year as part of a date field, 

2 the remaining two digits of the year need to be added if the output format requires a four-digit 

3 year as part of the date field. 

4 While the foregoing examples refer only to the first dictionary 201, any of the examples 

5 are applicable to the second dictionary 202, and any of the foregoing examples of algorithms can 

6 also be included in the second dictionary 202. Moreover, the foregoing are merely examples of 

7 mapping algorithms contained in the first dictionary 201 and the second dictionary 202, and 

8 those skilled in the art will recognize that the algorithms of the data dictionaries are not limited 
•^9 to the specific examples given herein. 

lljO As can be seen in Figure 1, an audit log 210 is included in one embodiment of the 

ii 1 invention, for electronically storing the input transaction data 204 and/or the output transaction 

*B 

pi 2 data 206. Along with the input data and/or output data, a date/time stamp can be added to the 

V. 

133 data stored in the audit log. Storage of the audit log can be in a database, an ASCII flat file, or 

El 4 other file format, and can exist in any form of computer-readable memory, including hard disk, 

Q5 disk array, removable media, diskette, or other storage medium. 

Q 

16 As can be seen in Figure 8, in one embodiment, the system 200 can be part of a 

17 computer network 550, so that the system receives input transaction data 204 from a computer 

1 8 500 via the network and/or sends output transaction data 206 to a computer 501 via the network. 

19 Returning again to Figure 1, when the system 200 is part of a network 550, the audit log can 

20 further include transaction identification data 502, i.e. data identifying the computer from which 

2 1 the input transaction data 204 was sent and/or data identifying the computer to which the output 

22 transaction data 206 was sent. Transaction identification data 502 stored in the audit log can also 
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1 include data identifying a user using the computer from which the input data was sent, so that the 

2 audit log comprises a complete transaction history log, or audit trail. 

3 Figure 8 shows another embodiment of the present invention providing warehousing 

4 storage capabilities, i.e. the system can store a transaction after it is translated into the core 

5 structure. Once a first input transaction 204 is stored in warehousing storage 560, one or more 

6 additional transactions 204 of differing type from the first can be received by the system, 

7 translated into the core structure, and then an output transaction 206 can be constructed using the 

8 data from the additional transaction(s), supplemented by data from the first stored transaction. 
Q 9 Additionally, a plurality of input transactions 204 can be received, translated into the core 
1^10 structure, and stored in warehousing storage 560. Along with the input transactions 204, 

; jf 1 1 transaction identification information 502 can be stored, including data identifying the computer 

12 from which the input transaction data was sent 503, data identifying the computer to which the 

p 13 output transaction file will be sent 504, and/or data identifying a user using the computer from 

q 14 which the input data was sent 505. Thus, an output transaction 206 can be constructed using 

Q 15 stored transaction data in the core data structure, originating from the plurality of input 

16 transactions 204. The data used in constructing the output transaction 206 can be selected based 

17 on the stored transaction identification data 502 accompanying the stored transaction data. The 

18 warehousing storage 560 can be embodied as a component of the translation system 200, or 

19 alternatively, can exist as a separate component outside of the system 200. 

20 In a further embodiment of the present invention, the translation engine is capable of 

2 1 generating a plurality of output transactions from a single input transaction. Each of the output 

22 transactions may be based on portions of the input transaction data not used for the other output 

23 transactions. For example, the input transaction might represent a customer returning 
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1 merchandise to a supplier. In this scenario, the translation engine splits a single return 

2 transaction received as input transaction data into three output transactions: a customer credit 

3 transaction, a return to inventory transaction, and a debit sales transaction. The plurality of 

4 output transactions, in addition to being different types of transactions from one another, can also 

5 be functional duplicates of identical or similar transactions which are sent to different computers 

6 as output transactions. For example, in a return transaction including data representing returns to 

7 two different sources, the output transactions may both be return transactions to be received by 

8 two different computers. Another example would be for a return of item A to source X and a 
*2 9 return of item B to source Y. The output transactions may comprise output transaction data sent 

; 10 to computer L at source X for the return of item A, and output transaction data sent to computer 

J^ll M at source Y for the return of item B. 

12 It should be appreciated by those skilled in the art that one or more of the functional 

q 13 components may be constructed out of custom, dedicated electronic hardware and/or software, 

p 14 without departing from the present invention. Thus, the present invention is intended to cover all 

13 15 such alternatives, modifications, and equivalents as may be included within the spirit and broad 

16 scope of the invention as defined only by the hereinafter appended claims. 
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